package cn.tedu.csmallproductzxj.controller;

import cn.tedu.csmallproductzxj.ex.ServiceException;
import cn.tedu.csmallproductzxj.web.JsonResult;
import cn.tedu.csmallproductzxj.web.ServiceCode;
import lombok.extern.slf4j.Slf4j;
import org.springframework.validation.BindException;
import org.springframework.validation.FieldError;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;

import javax.validation.ConstraintViolation;
import javax.validation.ConstraintViolationException;
import java.util.List;
import java.util.Set;
import java.util.StringJoiner;

/**
 * 全局异常处理机制
 */
@Slf4j
@RestControllerAdvice //让所有的异常都来这个类中处理
public class GlobalExceptionHandler {
    //异常信息应该由抛出的人来描述清楚错误原因 全局异常处理机制只负责呈现信息，不负责描述信息
    @ExceptionHandler
    public JsonResult handleServiceException(ServiceException e){
        return JsonResult.fail(e);
        //return JsonResult.fail(e); 选择另外一种重载的方式

//        JsonResult jsonResult=new JsonResult();
//        jsonResult.setState(2);
//        jsonResult.setMessage(e.getMessage());
//        return jsonResult;
    }


    @ExceptionHandler
    public JsonResult handleRuntimeException(BindException e) {
        // 使用以下方式时，如果有多个检查错误，
        // 将获取其中某1个检查注解中配置的message值，但无法确定到底是哪一个
        // String message = e.getFieldError().getDefaultMessage();
        //好处：简单 坏处：多个错误的时候不知道哪个错误，（从多个错误中随机取出一个）因为每次只告诉一个错误，下一次再来的时候可能还是错误的

        // 使用以下方式时，如果有多个检查错误，将可以反馈所有错误的信息
        //多个线程同时使用 访问同一个变量，要对变量做修改,需要使用线程安全的
        //获取错误的信息文字
        //String message=e.getFieldError().getDefaultMessage();
        //获取多个错误的方法：
        //好处：提示多个错误信息
        // 缺点：比较耗时，因为会检查每个错误，检查出第一个错误，还要去检查后面的错误（后面的错误没有必要去检查）
        //两种方法综合来说第一种更好，第二种方法在服务器忙的时候是一种雪上加霜的做法


        //StringBuilder方法，有点low~~
/*        StringBuilder stringBuilder=new StringBuilder();
        List<FieldError> fieldErrors = e.getFieldErrors();
        for (FieldError fieldError : fieldErrors) {
            stringBuilder.append(fieldError);
        }
        return stringBuilder.toString();*/
//        StringJoiner stringJoiner = new StringJoiner("，", "请求参数格式错误，", "！");
//        List<FieldError> fieldErrors = e.getFieldErrors();
//        for (FieldError fieldError : fieldErrors) {
//            stringJoiner.add(fieldError.getDefaultMessage());
//        }
//        return stringJoiner.toString();

        String message=e.getFieldError().getDefaultMessage();
        return JsonResult.fail(ServiceCode.ERR_NOT_FOUND,message);
    }

    //处理根据id删除的异常
    @ExceptionHandler
    public JsonResult handleConstraintViolationException(ConstraintViolationException e) {
        String message=null;
        Set<ConstraintViolation<?>> constraintViolations=e.getConstraintViolations();
        for (ConstraintViolation<?> constraintViolation : constraintViolations) {
            message = constraintViolation.getMessage();
        }
        return JsonResult.fail(ServiceCode.ERR_CONFLICT,message);
    }

    //多个异常的方法，子集写在上面，必须要有一个throwable方法，这样客户端就不会出现500错误，
    // 但是这并不是处理异常的最优解，因为各种没有被针对性处理的异常都会由此处处理，所以无法准确响应到客户端
    //在处理过程中，必须了解并记录异常的类型，出现异常的原因等，
    // 并且后续应该补充针对性处理这些异常的方法，
    // 在处理过程中，可以使用e.printStackTrace() 以查看异常的跟踪信息，
    // 注意：在生产环境（项目上线）中，是通常禁止使用此方法，因为此方法执行效率很低，而且是一种阻塞的方法（就是说它运行的时候其他方法运行不了）
    //怎么解决危害：在开发项目的过程中，会不断的增加针对性的异常方法，
    // 走到throwable 的方法的代码就越来越少，他不能算真正的处理异常的方法，
    // 就是为了避免出现500错误 所以慢慢的就会不存在了在上线的时候注释掉就行
    //除了用e.printStackTrace()，还可以用日志来输出异常的信息
    @ExceptionHandler
    public JsonResult handleThrowable(Throwable e) {
        String message="\"服务器忙，请稍后再尝试，或联系系统管理员！（在开发过程中，看到此消息，应该检查出现异常的原因，并补充对此类异常的针对性的处理）";
        log.warn("程序执行过程中出现Throwable！");
        log.warn("异常类型：{}", e.getClass().getName());//可以用这两个
        log.warn("异常信息：{}", e.getMessage());
        log.warn("异常跟踪信息如下：", e); // 输出异常信息时，第1个参数中不要使用占位符,这个少用，输出的信息太多，效率相对不高
        // e.printStackTrace();
        return JsonResult.fail(ServiceCode.ERR_UNKNOWN,message);
    }
}
